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Reply to Office Action of January 16, 2007 

REMARKS/ARGUMENTS 

Favorable reconsideration of this application, as presently amended and in light of the 
following discussion, is respectfully requested. 

Claims 1-20 are pending, with Claims 1 1-20 amended by the present amendment. 

In the Official Action, Claims 1 1-20 were rejected under 35 U.S.C. §101; and Claims 
1-20 were rejected under 35 U.S.C. §103(a) as being unpatentable over Nataraian et al. (U.S. 
Patent 6,505,244, hereinafter Nataraian) . Evans (U.S. Patent 5,694,524) and Yates et al. (U.S. 
Patent 6,330,586, hereinafter Yates) . 

Claims 1 1-20 are amended as suggested in the Official Action so as to overcome the 
outstanding rejection under 35 U.S.C. §101. No new matter is added. 

Briefly recapitulating. Claim 1 is directed to a method for modeling video 
teleconferencing network reliability. The method includes obtaining historical data for 
multiple video conferences, and storing the historical data in a call history table (e.g., item 
102 in Figure 3). The historical data is referenced to video teleconferencing equipment 
vendor or model identification information (e.g., specification, page 7, line 30 - page 8, line 
22; Figures 3-5). The method also includes executing a modeling algorithm (e.g., item 101 in 
Figure 6; specification, page 9, lines 1-7) that produces a model representing the historical 
data, analyzing the model to identify characteristics associated with undesirable outcomes for 
the video conferences (e.g., specification, page 9, line 16 - page 10, line 2), and configuring a 
video teleconferencing network to avoid at least one of the identified characteristics 
associated with undesirable outcomes (e.g., specification, page 10, line 15 - page 11, line 6). 
hidependent Claims 1 1 and 20 are directed to a corresponding computer program product and 
data processing system. 
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The first issue is whether Nataraian or Yates discloses or suggests Appellants' 
historical data referenced to video teleconferencing equipment vendor or model identification 
information (e.g., specification, page 7, line 30 - page 8, line 22; Figures 3-5), 

The second issue is whether Nataraian discloses or suggests Appellants' obtaining 
historical data for multiple video conferences, and storing this multi-conference historical 
data in a call history table. 

The third issue is whether Nataraian discloses or suggests Appellants' steps of 
executing a modeling algorithm (e.g., item 101 in Figure 6; specification, page 9, lines 1-7) 
that produces a model representing the historical data, analyzing the model, and configuring a 
video teleconferencing network based on the analysis. 

Nataraian describes a feedback-based adaptive network wherein at least a portion of 
the network elements report operating information relating to network conditions to a 
centralized data store. The information which is reported to the data store is analyzed by a 
policy engine which includes a plurality of appUcation specific plug-in policies for analyzing 
selected information fi-om the data store and for computing updated control information based 
upon the analysis of the information. The updated control information is fed back to selected 
network elements to thereby affect operation of the selected elements. 

Nataraian does not disclose or suggest Appellants' call history table or Appellants' 
steps of executing a modeling algorithm that produces a model representing the historical 
data, analyzing the model, and configuring a video teleconferencing network based on the 
analysis. 



10 



Application No. 10/045,303 

Reply to Office Action of January 16, 2007 

A. Both Nataraian and Yates do not disclose or suggest Appellants' historical data 
referenced to video teleconferencing equipment vendor or model identification 
information. 

As acknowledged in the Official Action/ Nataraian does not disclose or suggest 
Appellants' historical data referenced to video teleconferencing equipment vendor or model 
identification information. To cure this deficiency, the Official Action points to Yates, 
column 5, line 66 - colimm 6, line 12. However, this passage of Yates merely amplifies an 
earlier discussion of benefits (not data) associated with various disclosed object-oriented 
software modules and states "Other potential benefits of the access arrangements for an 
individual user might include the following: single contact point for services from different 
vendors; easy invocation and use of services from different vendors; consistent presentation 
of services across different vendors; integrated accounting and charging for a service set 
supplied by multiple vendors^ security from unauthorised invocation and use of services; 
privacy from unauthorised access to service usage and service content information." This 
statement of benefits is not "historical data referenced to video teleconferencing equipment 
vendor or model identification information," let alone Appellants' historical data stored in a 
call history table or Appellants' model representing the historical data. That is, these 
enumerated benefits are not data at all. 

Furthermore, the objects discussed in Yates serve to hide vendor specific features and 
anomalies, rather than to store and model vendor specific features. That is, Yates ' recitation 
of vendor-related user/system benefits (i.e., 1) single contact point for services from different 
vendors; 2) easy invocation and use of services from different vendors; 3) consistent 
presentation of services across different vendors; and 4) integrated accounting and charging 
for a service set supplied by multiple vendors) are benefits only because any vendor specific 



' Official Action, paragraph 3a. 
^ Official Action, paragraph 3b. 
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data is hidden or harmonized with a generic model. Nothing about the objects of Yates 

suggest storing or modeling vendor specific features. 

B. Nataraian does not disclose or suggest Appellants' obtaining historical data for 
multiple video conferences, and storing this multi-conference historical data in a 
call historv table. 

The Official Action refers to Figxu-e 15 of Nataraian for a disclosure of Appellants' 
storing this multi-conference historical data in a call history table.^ This figure shows an 
example of a flow diagram for a data store event handler reporting procedure 1500. 
Procedure 1500 may be implemented via the event handling entity 272 residing at data store 
252. One responsibility of event handler 272 is to continually monitor the data store for new 
or updated control information which has been generated by the network elements or by the 
policy engine 254. When event handler 272 detects the occurrence or availability of a new 
control parameter, it notifies the event server 270 which distributes the event notification 
message onto the appropriate network element(s).'* Thus, data store 252 stores data relative 
to events used by or relating to event handler 272. However, this event data is not 
Appellants' historical data for multiple video conferences. That is, the event data of 
Nataraian has no persistence fi*om one process to another. Said differently, the event data of 
Nataraian pertains to a single video teleconference, not to multiple video teleconferences as 
required by Appellants' claims. 

To understand this point, it is first necessary to identify what constitutes event data in 

Nataraian . While the word "event" is used 247 times in Nataraian . the term * event' is never 

explicitly defined. However, an implied definition may be derived firom the following 

examples of events disclosed in Nataraian : 

• ...notification for specified events, such as, for example, the availabilitv of 
updated control information at data store 252.^ 

^ Official Action, paragraph 3a. 

^ Natarajan, column 25, lines 27-55, 

^ Nataraian. column 10, lines 21-25. 
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• Yet another purpose of the event handler is to monitor specified network 
elements, and report the detection of specified events (e.g. detected errors) to 
event server 270. In an alternate embodiment, the event handler is statically pre- 
configured so that when it is initialized, it automatically monitors a specified 
network element for specific types of events and reports detected events to event 
server 270. For example, when an error is detected by network element 204A, the 
event handler 274A will report the error to event server 270 to be forwarded to 
other network and/or control elements (e.g. policy engine 254), which may be 
interested in this type of information.^ 

• Event handler 272 continually monitors the data store for updated control 
information and other events .^ 

• The policy engine may either repeatedly poll the data store for updated network 
data, or rely on an event service to be notified that a change in the network 
conditions has occurred .^ 

• The application specific policy may be automatically loaded upon on initialization 
of the policy analysis procedure, or may be loaded subsequently upon the 
occurrence of an event, such as, for example, the execution of a specific user 
application .^ 

• The event handler 274A may initially consult a local configuration file (not 
shown) in order to determine which events the network element is to register for at 
the event server 270.^^ 



However, none of these events are related to multiple video teleconferences as 
required by Appellants' claims. That is, there is no indication that an error of one process 
(e.g., conference) to be used in another process (e.g., conference). There also is no rationale 
for an error of one process (e.g., conference) to be used in another process (e.g., conference). 
Similarly, there is indication that any of the other examples of events described in Nataraian 
arising in a first process (e.g., conference) would be applicable to a second process (e.g., 
conference). 

The Official Action also cites to column 7, lines 12-43 of Nataraian for a disclosure of 

Appellants' claimed storing of historical data of multiple conferences in a call history table. 

Appellants traverse this finding and note that the cited passage of Nataraian recites: 

"The feedback-based adaptive network of the present invention utilizes a 
technique wherein at least a portion of the network elements (e.g., 204A, 

* Natarajan, column 10, lines 41-57. 

^ Natarajan , column 10, line 67 - column 1 1, line 1. 

^ Natarajan , column 13, line 66 - column 14, line 2. 

' Nataraian . column 15, lines 42-46. 

'° Nataraian. column 19, lines 25-28. 
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204B, 208A, 208B, etc.) report network information relating to network 
conditions to a centralized data storage entity (e.g., data store 252). The 
reported data corresponds to information relating to the current condition or 
status of each of the reporting network elements in the network . The 
information which is reported to the data store 252 is analyzed by a policy 
engine 254. The policy engine 254 includes a plurality of application specific 
plug-in policies for analyzing application specific information from the data 
store and for computing updated control information based upon the analysis 
of the information . The updated control information may include any type of 
information, parameters, and/or actions which may be used to affect the 
operation of one or more network elements. The updated control information 
is then fed back to selected network elements to thereby affect operation of 
the selected elements and/or network. Typically, when the operation of a 
network element has been affected, its corresponding operating parameters 
and/or operating information will change. The changed operating parameters 
are then reported to the data store 252 and analyzed by the policy engine 254. 
The policy engine may then generate new or updated control information or 
parameters for affecting the operation of selected elements in the network. In 
this way, the network of FIG. 2 is configured to adapt to changing conditions 
in the network by providing a dynamic feedback mechanism. Using this 
dynamic feedback mechanism, selected network elements may be 
dynamically and automatically reconfigured to cause the performance of 
various aspects of the network to conform with desired performance criteria." 

Appellants first submit that the above-cited passage of Natarajan discloses nothing related to 
call history or a call history table. The only data apparently stored in this passage is "changed 
operating parameters are then reported to the data store 252." However, neither the recited 
changed operating parameters nor any other information (e.g., the control information and 
parameter information analyzed by the policy engine 254) is call history data, let alone call 
history data of multiple video conferences. 

First, as with the previous discussion of 'events', there is no indication that "current 
conditions" of equipment involved in one process (e.g., conference) are used in another 
process (e.g., conference). There also is no rationale for "current conditions" of equipment 
involved one process (e.g., conference) to be used in another process (e.g., conference). The 
process, events and models of Natarajan sure directed exclusively to single video 
teleconferences, and not to management of multiple video teleconferences via use of 
historical data. 
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Indeed, the only reference to a video teleconference in Nataraian is found relative to 

the example of Figures 16-18 CTJsing the network illustrated in FIG. 16, various aspects of 

the present invention will now be described by way of example in which a video 

teleconference is established between userl (1602) and user2 (1620). The video 

teleconference example is described in greater detail with respect to FIGS. 17 and 18 of the 

drawings.")-'^ A review of the entirety of column 29, line 36 - colvimn 33, line 62 reveal that 

the events monitored relate to a single video teleconference, not to multiple video 

teleconferences as required by Appellants' independent claims. Thus, at best, Nataraian 

discloses the storing of historical (event) data relative to the management of a single ongoing 

video teleconference. Nataraian does not disclose or suggest storing historical (event) data 

from one video teleconference to be used in a second video teleconference, as required by 

Appellants' citation of "multiple conferences." 

C. Nataraian does not disclose or suggest Appellants' steps of executing a modeling 
algorithm that produces a model representing the historical data, analyzing said 
model, and configuring a video teleconferencing network based on said analysis. 

The passages cited in the Official Action relative to Appellants' modeling refer to the 

previously discussed Figures 16-18 of Nataraian . These figures provide an illustrative 

example of how various network elements interact with each other to form a feedback-based 

adaptive network. In particular. Figure 17 shows a flow diagram of how the feedback-based 

network of Figure 16 adapts to changing conditions in the network as a video teleconference 

is initiated between user 1 and user 2. A video teleconference application between user 1 and 

user 2 is one example of a user application which may require additional bandwidth in order 

to provide a satisfactory level quality for using the application to service multiple users across 

the network. Thus, the video teleconference example may be abstracted to be applied to any 

user application requiring additional network resources to provide a satisfactory level of 

Natarajan , column 29, lines 53-58. 
*^ Official Action, paragraph 3a. 
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quality for the application to run over a network environment. When a video teleconference 
begins between users 1 and 2, the network may respond by initiating one or more bandwidth 
policies at the policy engine 1654 and may also respond by initiating one or more 
policies/procedures at the monitor system 1662.^^ 

At 1704 the frame relay CIR policy is initiated at the policy engine 1654 if this pohcy 
has not aheady been initiated. While the frame relay CIR policy is being initiated by the 
policy engine at 1704, a CIR policy monitor procedure is concurrently initiated (1716) at 
monitor system 1662, if this procedure has not already been initiated. At 1706, each of the 
links a, b, c, d of Figure 16 reports the number of packets dropped on that link to data storage 
1652. The frame relay CIR policy at the policy engine 1654 uses this data to generate (1708) 
updated CIR parameter values for each of the respective links. The updated CIR parameter 
values generated by the policy engine are then written (1710) into the data store 1652. Once 
the appropriate network elements have been notified of changed network conditions, each of 
the network elements may retrieve a respective updated CIR parameter information from the 
data store 1652 and then update its configuration using the updated CIR parameter 
information.^"* 

In the CIR policy monitor procedure of FIG. 17, the quality monitor system 1662 
(FIG. 16) may concurrently and continuously monitor the effectiveness of the frame relay 
CIR policy implemented by the policy engine. In the example of FIG. 17, the effectiveness of 
the frame relay CIR policy is measured by analyzing the number of packets dropped at each 
of the respective links A, B, C, D, and comparing this data to predetermined criteria or 
guideUnes. Thus, for example, at 1718, the reported number of packets dropped for links A, 
B, C, D are analyzed and compared to a predetermined threshold in order to evaluate the 
effectiveness of the frame relay CIR policy implemented by the policy engine. A 

" Nataraian, colunin 29, line 36 through column 30, line 66. 

"Id. 
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determination is then made (1720) as to whether the frame relay CIR policy is effective in 
maintaining the number of dropped packets on each or any of the respective links beloMr the 
predetermined threshold value. If it is determined that the cvirrent frame relay CIR policy is 
effective in maintaining the number of dropped packets on each of the respective links below 
a predetermined threshold, the quality monitor system 1662 may wait (1722) a specified time 
interval (e.g., 0-30 minutes) before re-evaluating the effectiveness of the current frame relay 
CIR policy by analyzing newly updated information relating to the number of packets 
dropped at each of the respective links. 

However, contrary to the Official Action, none of the data monitoring and analysis of 
these, or any other, pcissage of Nataraian relates to Appellants claimed executing a modeling 
algorithm that produces a model representing the historical data, anal3^ing said model, and 
configuring a video teleconferencing network based on said analysis. That is, for the 
reasons previously presented, Nataraian does not monitor or use Appellants' claimed 
historical data. Also, the monitored, stored and analyzed event data of Natarajan is not used 
for configuring a video teleconferencing network. Instead, the data is used to assess the 
viability of a current frame relay CIR policy. Nothing in Natarajan discusses configuring or 
reconfiguring a video teleconferencing network based on the event data. 



Nataraian, column 31, lines 33-57. 
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Accordingly, in view of the present amendment and in light of the previous 

discussion, AppUcants respectfully submit that the present appUcation is in condition for 

allowance and respectfully request an early and favorable action to that effect. 



Respectfully submitted. 
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